Firefox for Enterprise Community Forum

Hi all,

For quite a while I'm working together with others on a voluntary base (nobody gets money) as members of a computer-club, a charitable NGO and NPO (in German: gemeinnütziger Verein) for seniors in order to bring them closer to the use of digital devices and media. It's not only teaching, but administrating the hard- and software as well.

I can remember that it was possible in former versions of Firefox to include at least a script into "defaults->prefs". I think it was user.js (not sure) in the installation folder to define common preferences to be fixed, like proxi settings. It always worked well, preventing non-privileged users from making any unwanted changes. As a I found out there must have been a very similar way to include add-ons (like uBlock Origin).

Unfortunately all content I found was older than about 10 years. When trying setting up Firefox as it is now, my test system didn't care about anything I've tried.

I'm talking about > 50 Windows-PC having in average 3 user profiles each (for teaching more than 400 members). We are amateurs regarding PC administration, except some network ex-professionals. "Baking" installation media including our needs, as I already found on Mozilla's pages, seems to be beyond our abilities as well as distributing a fitting profile (we don't have a MS-server), not speaking about Group Policies.

Is there any usable guideline for people like us? Today, each FF-installation looks different and I would like to unify this as easy as possible.

Greetings!

I am using the firefox enterprise version and I have noticed an issue that the browser does not capture mouse events when the pointer is at rightmost edge of the firefox window. For example, on this website near the edge the pointer would initially focus on the scroll bar and then lose focus at the edge (see attached images).

This issue does not persist on x11, and only seems to exist on wayland. It also exists on other flavours of firefox on wayland.

If more information is required, feel free to send me a ping.

Hi,

I am having the issues on more than 1 pc that after updating the firefox esr 128 version to 140 esr version, the firefox does not work properly, specially with xWiki. when i click on xwiki (on-premis server), i can read the contents and all. but when i click edit then it shows the blank page. this is very odd as it happens after updating to 140 version. picture is attached.

Thanks Sheras

How do I lock the Microsoft Purview settings in the attached image using intune, so users cannot change them.

I have been able to make it that they cant disable or remove the extension but cannot figure out how to make it that they cant change the settings. I did try making a json file but it does not seem like Firefox uses it.

I've been struggling for months to standardize a deployment of Firefox ESR across various client environments that reliably auto-updates and doesn't cause UAC prompts and XULRunner profile error pop-ups(I work in IT).

We deploy Firefox ESR in bulk on machines via a batch script which runs as SYSTEM, with msiexec /i and /qn flags.

Firefox installs fine, but then users are typically met with a UAC prompt when they first try to run Firefox. If they decline, then the UAC prompt comes back again next time and often fails to update at all, so the machine is left on an older, vulnerable version.

Regarding the environment: we have deployed the Firefox ESR admx templates and enabled the relevant auto update settings in Group Policy. But only some machines seem to stay up to date, and it seems like this only happens if a user with local administrative privileges has run the program at least once.

What I find unusual is that Firefox seems to attempt to make a "Background Updater" scheduled task for every user that runs the software on each PC, but these users do not have administrative privileges, and the scheduled task is set to only run when that user is logged in. Obviously a scheduled task running as a user with limited privileges isn't going to be able to update files in the Mozilla/Firefox subdirectory in "Program Files" as by default that's read-only access for non-admin users. And, obviously, if a user with local admin privileges DOES log into the machine, then it can update once, but then the scheduled task that it creates for that user (now with admin privileges) will only run when that user logs in - and we don't login as "admin"-privileged users day-to-day.

So, various machines are out of date, running vulnerable Firefox 128 instead of 140 or 142 even though they're all deployed from the same image and have the same policies and restrictions, and ran the same installer for Firefox.

Is there some reason why the auto update scheduled task isn't created at installation time, when administrative privileges have been granted? It's very odd that it doesn't, because then every time a user logs into a machine it seems like Firefox ESR creates the background upgrade task under a non-admin user which simply won't work. I see machines having 4 or 5 background upgrade scheduled tasks, all created by Firefox ESR, and yet the software still won't update - there's a UAC prompt every time the program launches, and going to Help -> About shows "Restart Firefox to update..." but then when clicking the button to restart Firefox, we get the UAC prompt, user doesn't have privileges, so this goes around and around in circles.

Is there a reliable way to keep Firefox up to date without manually logging into each machine and going through the UAC prompts? Can we manually create a scheduled task with the correct user account that has privileges to actually upgrade Firefox?

The background auto update mechanism simply doesn't make sense to our team on a machine-wide install.

I am working on a stig for Mozilla Firefox and I'm trying to do a scap compliance scan but or some reason I am getting a score of zero on all systems. We do patch regularly and at some point one of the version upgrades caused our compliance scans stopped working. I need a fix and cannot find anything when searching for this issue.